Hi, I raised an issue more than a month ago about the program crashes on Windows.

Related issues and this PR will close it #52 .

The following is a record of my solution process.

Initially, based on the error log and running normally on my MacBook, I got some key information: This was mainly caused by the inability to read the target files correctly on the Windows platform.

In the past month or so, I have tried to solve this problem several times, but because Bun does not support Windows and the problem only occurs on Windows, there was no effective debugging solution for a long time.

This weekend, I also turned on a Windows machine at home, built the _lib related files on my MacBook, and shared them with Windows via SMB , and overwrote its files in node_modules directory. At this point, I finally have a relatively simple and effective solution to debug program running problems.

Solution process

According to the crash process of the program, I found that there are mainly the following problems:

dev service failed to start

In src/vite/plugins/dev.ts, /@fs —> /@fs/ is missing a slash, causing the dev service to start crashing. In order to prevent too many or too few slashes, I added a getFsPath to supplement the prefix (this method was also used later when solving other crash problems)

virtualStyles plugin cannot load style files

In src/vite/plugins/virtual-styles.ts, the path prefix of /@fs/ is also missing.

The above two steps solve the crash problem on Windows and also ensure that it can run normally on Mac.

Routes data is missing

As of this point, run dev works fine on Mac, but run dev on Windows only gets a Not Found route.

Printing the routes array correctly gets 6 initial routes on Mac, but only 1 on Windows.

To do this, start troubleshooting the routes data provider: routes_virtual, located in src/vite/plugins/virtual-routes.ts.

The problem here is that in buildStart, the Glob pattern matching condition is the complete file path, which will cause Windows to include the backslash \, which is not supported.

See: https:/ /github.com/sindresorhus/globby?tab=readme-ov-file#api

Note that glob patterns can only contain forward-slashes, not backward-slashes, so if you want to construct a glob pattern from path components, you need to use path.posix.join() instead of path.join().

Therefore, I narrowed the matching scope to only match within the rootDir range, and appropriately excluded the node_modules and dist directories, and successfully obtained the same routing file as the data source on Mac.

Component of Route is invalid

The next problem comes. On Windows, an invalid routing component will be prompted because the file path obtained does not support loading through dynamic import.

Therefore, in src/vite/plugins/virtual-routes.ts, a componentPath variable is declared for the target of dynamic import. For Windows, a relative path is used to introduce it.

The homepage cannot import React components

When we get here, the dev service and routing are normal, but when other routing is normal, an error will be reported on the homepage and components from vocs/components cannot be introduced.

The parsing and replacement process of the import path is found in src/vite/plugins/resolve-vocs-modules.ts. The relative path is also used to solve the import problem on Windows. See the comment of getRelativeLibDir.

At this point, the dev problem has been solved.

Pre-rendering failed

When I run run build, I get an error saying on windows, absolute paths must be valid file:// URLs. Received protocol d:. This problem is solved by using compatibleAbsolutePath in src/vite/prerender.ts.

At the same time, I have also fixed the problem that after the build is successful, but there will be only empty HTML files under Windows. Pre-rendering is also successful now.

Remaining problem

Windows currently cannot preview normally under run preview under the project, but by copying the build products to an independent Express service, it can be accessed normally. So there should be no big problem with the build product. It may be that there are still problems with the preview service program that need to be fixed.

In addition, there is still a problem with searching on Windows, and the target index cannot be searched.

But for these two problems, I plan to solve them through other PRs to prevent one PR from carrying too many code changes.

Some previews

Start the dev service on Windows Terminal and it can be used normally.

After building, it can get correct pre-rendered results.

Although it is not possible to directly preview the built product, normal access and routing switching can be achieved through the Express service.